@pokey Looks like meta updater have some problem on windows. If I run the lint:meta script on my own computer it works fine and works fine on Linux and mac, but windows on ci is failing. Probably have something to do with line endings?

Also I would prefer to remove the unsupported scope facet level. Since there's isn't really any difference between explicitly saying unsupported and not specifying the level at all.

I would argue for keeping unsupported. Otherwise there's no way to know if it is unspecified because it's unsupported or if we just haven't gotten around to indicating its support level yet

Yes I'm just doubting that we are ever going to actually do that :p
But sure let's keep it for now.

Yes I'm just doubting that we are ever going to actually do that :p

Sorry not sure I'm following: doubting whether we'll do what?

Yes I'm just doubting that we are ever going to actually do that :p

Sorry not sure I'm following: doubting whether we'll do what?

Getting around to actually going through all scope facets and specifying unsupported.

Getting around to actually going through all scope facets and specifying unsupported.

Exactly. That's why it's important to have the ability to distinguish between unsupported and just not having been specified yet. If we just take unspecified to mean it's unsupported, we won't be able to tell which ones are actually unsupported and which we just haven't gotten around to yet

Eg we could render the missing ones with a question mark in the docs to encourage people to contribute, and so they don't get the false impression it's not supported when really it is

@pokey Any ideas how to fix the lint:meta problem on windows?

Not sure but I'm not sure it's a good idea to use meta-updater for generating this .md file anyway. My instinct would be to do that during web build step. Is there some reason to prefer checking this file into source control?

I always prefer if documentation is in markdown. If I need to navigate to a webpage to read the docs I'm probably not gonna do it as often.

Yeah but this file is huge. Are you really going to read this file anyway? I had thought that the tables were supposed to be more for users, and that contributors would just look at the source code

I guess that works as well. Where do you want this placed instead?

Maybe we just generate it into docs folder during website build step and add that to gitignore? That's what we used to do with our api docs

Where do we have existing configuration for that I can look at?

I don't believe we do anything like that today. On second thought, though, we should prob do it with an MDX react component that imports the scope support tables

That sounds reasonable. Have you done anything like that before or do you have some documentation I could look at how to do that with docusaurs?

Just Google docusaurus MDX. We have some MDX stuff in our next.js root site as well. Look for files ending in mdx

If you get stuck let's discuss at meetup

@AndreasArvidsson why did you downgrade docusaurus?

@AndreasArvidsson why did you downgrade docusaurus?

It did not compile and I didn't aim to update docusaurus in this pull request; it's already large enough.

strange was working fine for me, but yeah agreed it's orthogonal

btw wdyt of f189f12 😄

(credit goes to https://docusaurus.io/feature-requests/p/hiding-parts-of-docs-in-autogenerated-sidebar)

strange was working fine for me, but yeah agreed it's orthogonal

Yeah if it would have worked fine I wouldn't really have cared, but I ran into major problems with pnpm and just reverting to main fixed it.

btw wdyt of f189f12 😄

Fine with me :)

yeah confirmed it's working; doesn't appear in sidebar https://deploy-preview-2451--cursorless.netlify.app/docs/ but can go directly to page so it is still deploying eg https://deploy-preview-2451--cursorless.netlify.app/docs/user/languages/cpp/

Nice. I'm happy with that.

Totally agree!